Adjusting different areas of a payment instrument image independently

ABSTRACT

The present disclosure involves systems, software, and computer-implemented methods for allowing independent adjustment for different areas of a payment instrument image. An example method includes updating an image property of an area of a clearing payment instrument image associated with a tangible payment instrument including a payee, a payor, an amount, and an authorization, the tangible payment instrument to be submitted for electronic transaction clearing, wherein the clearing payment instrument image is associated with a first value of the image property, the image property of the area is updated to a second value different than the first value of the image property, and the area of the clearing payment instrument image includes less than the entire clearing payment image; and storing the updated clearing payment instrument image in response to updating the image property.

CLAIM OF PRIORITY

This application claims priority under 35 USC §120 to U.S. patentapplication Ser. No. 14/256,425, filed on Apr. 18, 2014, the entirecontents of which are hereby incorporated by reference.

BACKGROUND

The present disclosure involves systems, software, andcomputer-implemented methods for allowing independent adjustment ofdifferent areas of a payment instrument image.

In check processing, physical payment instruments are scanned usingimage capture devices (e.g., scanners) to produce payment instrumentimages. These payment instrument images may be used in lieu of theoriginal physical payment instruments when clearing transactions betweenbanks.

SUMMARY

The present disclosure involves systems, software, andcomputer-implemented methods for allowing independent adjustment ofdifferent areas of a payment instrument image. In one general aspect, anexample method includes updating an image property of an area of aclearing payment instrument image associated with a tangible paymentinstrument including a payee, a payor, an amount, and an authorization,the tangible payment instrument to be submitted for electronictransaction clearing, wherein the clearing payment instrument image isassociated with a first value of the image property, the image propertyof the area is updated to a second value different than the first valueof the image property, and the area of the clearing payment instrumentimage includes less than the entire clearing payment image; and storingthe updated clearing payment instrument image in response to updatingthe image property.

In another general aspect, an example method includes receiving anoriginal payment instrument image from the remote storage location;presenting a clearing payment instrument image associated with theoriginal payment instrument image in a user interface in response toreceiving the original payment instrument image, the clearing paymentinstrument image associated with a first value of an image property;receiving an indication of an area of the clearing payment instrumentimage to update from the user interface; receiving an indication of asecond value of the image property from the user interface to which toupdate the indicated area of clearing payment instrument image, thesecond value different than the first value of the image property; andupdating the image property of the indicated area to the second value inresponse to receiving the indications of the area and the second valueof the image property.

In another general aspect, an example method includes updating an imageproperty of an area of a clearing payment instrument image associatedwith a tangible payment instrument including a payee, a payor, anamount, and an authorization, the tangible payment instrument to besubmitted for electronic transaction clearing, wherein the imageproperty of the area is updated to a second value different than a firstvalue of the image property associated with a rejected clearing paymentimage that is unsuitable for electronic transaction clearing, and thearea of the clearing payment instrument image includes less than theentire clearing payment image; and storing the updated clearing paymentinstrument image in response to updating the image property.

While generally described as computer-implemented software embodied onnon-transitory, tangible media that processes and transforms therespective data, some or all of the aspects may be computer-implementedmethods or further included in respective systems or other devices forperforming this described functionality. The details of these and otheraspects and implementations of the present disclosure are set forth inthe accompanying drawings and the description below. Other features,objects, and advantages of the disclosure will be apparent from thedescription and drawings, and from the claims.

DESCRIPTION OF DRAWINGS

FIG. 1 is a block diagram illustrating an example system for clearingfinancial transactions between banks.

FIG. 2 is a block diagram illustrating an example system for allowingindependent adjustment for different areas of a payment instrumentimage.

FIG. 3 is a diagram illustrating an example user interface to an exampleimage correction system in an initial state.

FIG. 4 is a diagram illustrating the example user interface after aphysical check has been scanned.

FIG. 5A is a diagram illustrating the example user interface after aphysical check with a low contrast region has been scanned.

FIG. 5B is a diagram illustrating the example user interface receivingan indication of an area to which to apply a contrast adjustment.

FIG. 5C is a diagram illustrating the example user interface afterperforming the contrast adjustment to the indicated area.

FIG. 6 is flow chart showing an example method for allowing independentadjustment of different areas of a payment instrument image.

FIG. 7 is flow chart showing another example method for allowingindependent adjustment of different areas of a payment instrument image.

FIG. 8 is flow chart showing another example method for allowingindependent adjustment of different areas of a payment instrument image.

FIG. 9 is flow chart showing an example method for allowing independentcontrast adjustment of different areas of a payment instrument image.

DETAILED DESCRIPTION

The present disclosure involves systems, software, andcomputer-implemented methods for allowing independent adjustment ofdifferent areas of a payment instrument image.

Generally, a bank receiving physical payment instruments for depositscans the payment instruments to produce original payment instrumentimages corresponding to the physical payment instruments. Paymentinstruments, in general, are non-cash instruments for exchanging valuefrom one party to another, such as, for example, checks, cashier'schecks, deposit slips, traveler's checks, or other instruments. Theseimages are processed to produce payment instrument images suitable foruse in the clearing process (clearing payment instrument images), whichare then submitted to an appropriate financial institution for clearing.In some cases, the original payment instrument images may bemonochromatic images (e.g., grayscale), color images, or other types ofimages, while the clearing payment instrument images may bemonochromatic images, bi-tonal (e.g., black and white) images, reducedcolor images, or other types of images.

In some cases, a clearing payment instrument image may not capture allthe necessary information on the check. For example, if the checkincludes a background or watermark image with multiple light and darkregions, the produced clearing image may include regions of lowcontrast, making it unsuitable for electronic processing.

The present disclosure describes techniques allowing independentadjustment of different areas of a payment instrument image. One examplemethod includes identifying an original payment instrument image, suchas a grayscale image, associated with a tangible payment instrument. Aclearing payment instrument image based on the original paymentinstrument image is then created, such as by converting a grayscaleimage to a bi-tonal image. The clearing payment instrument imageassociated with a first value for a particular image property. Anindication of an area of the clearing payment instrument image to adjustis received. A second value for the image property different than thefirst value may then be determined, and the image property of the areaof the clearing payment instrument image is updated based on the secondvalue of the image property. In some cases, the indications may bereceived by a user interface, which may limit the modifications a usermay perform on the clearing payment instrument image, such as notallowing the user to update image properties besides contrast.

Implementations according to the present disclosure may provide severaladvantages over prior techniques. Allowing different areas of a paymentinstrument image to be adjusted independently may enable electronicprocessing of checks that previously necessitated physical processing.Because such processing is punitively expensive, the present techniquesmay lead to cost savings. Further, by limiting users to only adjustingcertain property of the payment instrument image areas, potential fraudarising from user manipulation of check information may be avoided.Moreover, the present techniques may be performed proactively to correctlow quality payment instrument images before they are submitted forclearing. In this way, costs and delays related to rejected paymentinstrument images may be reduced. In addition, the present techniquesmay result in a reduction in ‘float’ time of payments associated withthe processed payment instrument images, which may reduce the potentialof a payment not being cleared within the allowable time window asspecified by the banking regulations. Such late payments may have to bewritten off by the depositing bank

FIG. 1 is a block diagram illustrating an example environment 100 forclearing financial transactions between banks. In operation, one or morepayment instruments 110 may be received at the bank branch 102, such asfrom bank customers seeking to deposit the payment instruments 110 intotheir respective accounts. The payment instruments 110 may be scanned byone or more scanners 106 to produce a set of associated paymentinstrument images. The payment instrument images may be sent by the bankbranch 102 to the bank central office 112, which may be processed by theclearing system 114. For payment instrument images associated withchecks drawn on banks with which the bank central office 112 has aclearing agreement 116 (e.g., trusted banks 122), the clearing system114 may send the payment instrument images to the other bank forclearing. For payment instrument images associated with checks drawn onbanks with which the bank central office 112 does not have a clearingagreement 116 (e.g., an trusted banks 122), the clearing system 114 maysend the payment instrument images to a Federal Reserve Bank 120 forclearing. Image correction systems 108 a-b, located at bank branch 102and bank central office 112, respectively, may be used to correctpayment instrument images either before the clearing process, or after aparticular payment instrument image has been rejected during theclearing process, such as by the Federal Reserve Bank 120 or one of thetrusted banks 118. More detail on the image correction systems 108 a-bis provided below relative to FIGS. 2-5.

As shown, environment 100 includes a bank branch 102. The bank branch102 may be a physical location associated with particular financialinstitution. In some cases, the particular financial institution mayoperate multiple bank branches at different locations. In someimplementations, the bank branch 102 may be a virtual bank branch, suchas a banking website, or an automated kiosk such as an automated tellermachine (ATM). For the purposes of the present example, the bank branch102 will be described as a physical branch location.

The bank branch 102 may include one or more tellers 104. In some cases,the tellers 104 may be stations within the bank branch 102 forprocessing deposits, withdrawals, and other financial transactions. Thetellers 104 may be customer service employees of the bank branch 102trained to operate the scanners 106, the image correction system 108 a,or other systems. In some cases, the tellers 104 may be ATMs, and thescanners 106 or the image correction system 108 a may be integrated intothe tellers 104.

The tellers 104 process payment instruments 110 presented by bankcustomers at the bank branch 102. In some cases, the payment instruments110 may include bank drafts, cashier's checks, money orders, depositslips, bearer notes, traveler's checks, or other types of financialinstruments. The payment instruments 110 may also be presented to thebank branch 102 electronically, such as in the form of paymentinstrument images.

The payment instruments 110 may be scanned by one or more scanners 106to produce payment instrument images. In some implementations, thescanners 106 may be multi feed check scanners operable to producegrayscale or other monochromatic images associated with each check. Thescanners 106 may also perform analysis on the payment instrument images,such as, for example, optical character recognition (OCR), magnetic inkcharacter recognition (MICR), image filtering, contrast adjustment,despeckling, and other analysis. In some implementations, externalhardware or software systems may interface with the scanners 106 inorder to perform image analysis on the payment instrument images.

In some cases, the scanners 106 may scan one or more of the paymentinstruments 110, and package the associated payment instrument imagesand extracted metadata from the checks (e.g., OCR or MICR data) into acash letter file. In some cases, the cash letter file may be formattedaccording to X9.37, X9.180, X9.187, or another standard.

The bank branch 102 also includes a image correction system 108 a. Inoperation, the image correction system 108 a allows an analyst to reviewpayment instrument images and make adjustments to different areas of thepayment instrument image independently from other areas. The operationof the image correction system 108 a is described in greater detailbelow. In some implementations, the image correction system 108 a may beused to proactively review payment instrument images at the bank branch102A before they are sent to the bank central office 112 for clearing.For example, the image correction system 108 a may take a cash letterfile including monochromatic and bi-tonal payment instrument images asinput, and allow an analyst to iterate through each image in the cashletter file to determine whether corrections need to be made, and toallow the analyst to make such corrections.

The environment 100 also includes a bank central office 112. In somecases, the bank central office 112 may be a regional or national officeof the financial institution associated with the bank branch 102. Thebank central office 112 may receive payment instrument images frommultiple bank branches associated with the financial institution forclearing. As shown, the bank central office 112 includes a clearingsystem 114. In operation, the clearing system 114 may examine receivepayment instrument images and associated metadata to determine how toclear transactions associated with the payment instrument images. Forexample, the clearing system 114 may determine that a particular paymentinstrument image is associated with a trusted bank 118. The clearingsystem 114 may send the payment instrument image, the metadataassociated with payment instrument image, or other information to thetrusted bank 118 to clear the transaction associated with the paymentinstrument image. This interaction between the bank central office 112and the trusted bank 118 may be governed by a clearing agreement 116between the financial institutions associated with the bank centraloffice 112 and the trusted bank 118. Such a clearing agreement 116 maydefine the terms by which transactions between the two institutions maybe cleared.

The clearing system 114 may also send payment instrument images andassociated metadata through the Federal Reserve Bank 120 for clearing.In such a case, the Federal Reserve Bank 120 brokers the transactionclearing between the bank central office 112 and the un-trusted bank 122associated with particular payment instrument image. In some cases, thebank central office 112 may attempt to clear payment instrument imagesdirectly with one of the un-trusted banks 122, such as in cases whereclearing the check to the Federal Reserve Bank 120 is notcost-effective.

As shown, the bank central office 112 includes a image correction system108 b. In operation, the image correction system 108 b allows an analystto review payment instrument images and make adjustments to differentareas of the payment instrument image independently from other areas.The operation of the image correction system 108 b is described ingreater detail below. In some implementations, the image correctionsystem 108 a may be used to proactively review payment instrument imagesat the bank central office 112 before they are sent to the trusted banks118, the Federal Reserve Bank 120, or the un-trusted banks 122 forclearing. For example, the image correction system 108 b may take a cashletter file including monochromatic and bi-tonal payment instrumentimages as input, and allow an analyst to iterate through each image inthe cash letter file to determine whether corrections need to be made,and to allow the analyst to make such corrections. The image correctionsystem 108 b may also allow an analyst to review and correct one or morepayment instrument images in response to a payment instrument image or abatch of payment instrument images being rejected by the trusted bank118, the Federal Reserve Bank 120, or an untrusted bank 122.

In FIG. 1 and the above description, interactions between the bankbranch 102, the bank central office 112, the trusted banks 118, theFederal Reserve Bank 120, and the un-trusted banks 122 may occur overcommunications networks connecting these components. In someimplementations, the communications may be encrypted. In some cases, thepayment instrument images and associated metadata sent between thedifferent components may be included in cash letter files sent over thecommunications networks between the components. In some cases, the cashletter file may be formatted according to X9.37, X9.180, X9.187, oranother standard. In some implementations, the physical paymentinstruments 110 may be exchanged between the components at differentpoints in the transaction clearing process. In some cases, the physicalpayment instruments 110 may not be exchanged, and may be archived at thebank branch 102, and/or the bank central office 112.

FIG. 2 is a block diagram illustrating an example system 200 forallowing independent adjustment of different areas of a paymentinstrument image. The system 200 includes a image correction system 108,also shown in FIG. 1 as 108 a-b. The image correction system 108includes an interface 232 which is operable to receive paymentinstrument image information from the scanner 202, a network 204, a cashletter file 206, or other sources. The processor 234 executes the imagecorrection component 240. In operation, the image correction component240 allows a user 208 to examine a payment instrument image, selectareas of the payment instrument image to adjust, to perform anadjustment on the selected areas, and the output the corrected image.

As shown, the system 200 includes a scanner 202. In someimplementations, the scanner 202 may be a multi-feed check scannerconnected to the image correction system 108. The image correctionsystem 108 may control the scanner 202 by sending it various commandsover the interface 232, such as a command instructing the scanner 202 tobegin scanning. The scanner 202 may send acquired images to the imagecorrection system 108 via the interface 232. In some implementations,the scanner 202 is connected to the interface 232 via universal serialbus (USB) connection. The scanner 202 may also be connected to the imagecorrection system 108 using other technologies, including, but notlimited to, Ethernet, RS-232, IEEE 1394, Peripheral ComponentInterconnect (PCI), Small Computer System Interface (SCSI), or otherinterconnection technologies. The scanner 202 may also communicate withthe image correction system 108 over a communications network, such asan Internet Protocol (IP) network.

In some cases, the scanner 202 is a multifeed check scanner operable toprocess multiple physical documents in a batch. The scanner 202 mayinclude a feeder mechanism to draw physical documents from the batch oneat a time into position for image capture. Capturing images may beperformed according to known techniques. In some cases, the scanner 202may include image processing functionality to improve the quality of thecaptured image, such as by reducing noise, despeckling, sharpening,adjusting contrast, or performing other processing. The scanner 202 mayalso perform data extraction, such as, for example, OCR, MICR, or otherprocesses. For example, the scanner 202 may read a routing number andaccount number printed in MICR ink on the physical document, and mayperform OCR on a handwritten amount on the physical document. In somecases, the scanner 202 may scan multiple physical documents and producea cash letter file containing images and extracted metadata associatedwith the physical documents.

The system 200 also includes a network 204. In some cases, the imagecorrection system 108 may be operable to interact with the network 204to obtain one or more payment instrument images. For example, if aparticular batch of payment instrument images has been rejected aslow-quality, and the original monochromatic images of the checks are notavailable, the image correction system 108 may send a request over thenetwork to a location storing the monochromatic images to retrieve themfor further processing. In some cases, the image correction system 108may receive payment instrument images for review in the form of cashletter files.

System 200 also includes a cash letter file 206. In some cases, theimage correction system 108 may be provided with a particular cashletter file 206 for processing. For example, the cash letter file 206may be loaded into the image correction system 108, such as by storingthe cash letter file 206 on a disk included in the image correctionsystem 108 (not shown), and opening the cash letter file 206 with theimage correction component 240.

The image correction system 108 may be a computing device or set ofcomputing devices operable to receive payment instrument images andallow independent adjustment of different areas of the images. In someimplementations, the image correction system 108 may be a computingdevice executing one or more software programs to perform these actions.The image correction system 108 may include an operating system forcontrolling its execution and operation, including, but not limited to,MICROSOFT WINDOWS, LINUX, APPLE OS X, APPLE IOS, ANDROID, UNIX, BSD, orother operating systems. The image correction system 108 may alsoinclude other standard computing components, such as, for example, oneor more memories, one or more input devices such as keyboards, mice,touch screens, or other devices, one or more output devices such asdisplays, speakers, or other devices, or other computing components.

As shown, the image correction system 108 includes an interface 232. Theinterface 132 is used by the image correction system 108 forcommunicating with other components, such as the scanner 202, thenetwork 204, and a data location for the cash letter file 206.Generally, the interface 132 comprises logic encoded in software and/orhardware in a suitable combination and operable to communicate withthese components. More specifically, the interface 132 may comprisesoftware supporting one or more communication protocols associated withthe components allowing information to be exchanged between the imagecorrection system 108 and the components.

The image correction system 108 includes a processor 234. Althoughillustrated as a single processor 234 in FIG. 2, two or more processorsmay be used according to particular needs, desires, or particularimplementations of environment 100. Each processor 234 may be a centralprocessing unit (CPU), a blade, an application specific integratedcircuit (ASIC), a field-programmable gate array (FPGA), a graphicsprocessing unit (GPU) or another suitable component. Generally, theprocessor 234 executes instructions and manipulates data to perform theoperations of the image correction system 130.

The image correction system 108 includes a image correction component240. In some implementations, the image correction component 240 is asoftware application operable to acquire and present payment instrumentimages to the user 208, and allow the user to adjust of different areasof the payment instrument images independently from one another.

Regardless of the particular implementation, “software” may includecomputer-readable instructions, firmware, wired and/or programmedhardware, or any combination thereof on a tangible medium (transitory ornon-transitory, as appropriate) operable when executed to perform atleast the processes and operations described herein. Indeed, eachsoftware component may be fully or partially written or described in anyappropriate computer language including C, C++, JAVA, VISUAL, assembler,PERL, PYTHON, any suitable version of 4GL, as well as others. Whileportions of the software illustrated in FIG. 2 are shown as individualmodules that implement the various features and functionality throughvarious objects, methods, or other processes, the software may insteadinclude a number of sub-modules, third-party services, components,libraries, and such, as appropriate. Conversely, the features andfunctionality of various components can be combined into singlecomponents as appropriate.

The image correction component 240 includes a image handler 242. Inoperation, the image handler 242 may receive or extract paymentinstrument images from the various components, and perform variousprocessing and/or analysis operations on the images. For example, theimage handler 242 may perform initial adjustments to a monochromaticpayment instrument image to produce the corresponding bi-tonal image topresent to the user 208 through the user interface 246. The imagehandler 242 may enhance, despeckle, sharpen, adjust contrast, or performother operations on a particular payment instrument image. In somecases, the image handler 242 may extract information from the paymentinstrument image, such as by performing MICR or OCR processing toextract payment details from the payment instrument image. As previouslydiscussed, this analysis may be performed elsewhere, such as in caseswhere the image correction system 108 is presented with the cash letterfile including this information. The image handler 242 may also beoperable to control the scanner 202 to obtain payment instrument imagesof physical documents, such as by issuing commands to control theoperation of the scanner 202.

The image correction component 240 includes an image adjuster 244. Inoperation, the image adjuster 244 performs adjustments to an originalpayment instrument image to produce a clearing payment instrument image.In some implementations, the image adjuster 244 applies a filter to amonochromatic payment instrument image to produce a correspondingbi-tonal payment instrument image. For example, the image adjuster 244may examine the monochromatic payment instrument image, and produce abi-tonal payment instrument image where every pixel corresponding to apixel of the monochromatic payment instrument image with an intensitygreater than a desired contrast value is set to black, and all of thepixels are set to white. By adjusting this desired contrast value,different bi-tonal image representations of the monochromatic paymentinstrument image can be produced. In some cases, the image adjuster 244is controlled by the user interface 246, such as by the slider componentshown in FIGS. 3-5 and discussed below. In such cases, the imageadjuster 244 may produce a new bi-tonal image each time the state of theslider component changes, such that the user interface 246 provides theuser with an updated bi-tonal image based on their current contrastvalue selection. In some implementations, the image adjuster 244 mayalso allow other adjustments, including, but not limited to, colorweighting, noise reduction, despeckling, or other adjustments.

The image correction component 240 includes a user interface 246. Inoperation, the user interface 246 may present the user with paymentinstrument images and associated metadata for analysis, allow adjustmentof the payment instrument images, or perform other actions. The userinterface 246 may be visual interface presented to the user 208 over adisplay associated with the image correction system 108 (not shown). Theuser interface 246 may include standard visual computing components,such as buttons, text boxes, sliders, combo boxes, or other components.Examples of the user interface 246 are described in greater detailrelative to FIGS. 3-5.

FIG. 3 is a diagram illustrating an example user interface 300 to anexample image correction system in an initial state. The user interface300 includes a bi-tonal image pane 302, and a monochromatic imagedisplay pane 304. The display panes 302 and 304 are populated withimages of the check upon scanning, as shown in the subsequent figures.The user interface 300 also includes a scan button 306 that willinitiate the check scanning process when actuated. In some cases,actuating the scan button 306 causes the image correction component 240of FIG. 2 to interact with the scanner 202 to acquire one or morepayment instrument images. The user interface 300 also includes acontrast slider 308 used to adjust the contrast of a bi-tonal imagedisplayed in the bi-tonal image pane 302. Operation of this component isdescribed in more detail below.

FIG. 4 is a diagram illustrating an example user interface 400 after aphysical check has been scanned. As shown, a bi-tonal (black-and-white)payment instrument image 402 is displayed in the upper display pane, anda corresponding monochromatic (grayscale) payment instrument image 404is displayed in the lower display pane. Account information text box 406displays the parsed account information extracted from the MICR line 407that the bottom of the monochromatic payment instrument image 404. Insome implementations, the account information text box 406 may bepopulated by metadata included in a cash letter file for the particularpayment instrument image, or may be populated based on MICR analysisperformed locally. Amount text box 408 may similarly include an amountvalue populated by metadata included in a cash letter file for theparticular payment instrument image, or may be populated based on OCRanalysis of the payment instrument image performed locally.

The user interface 400 includes a rescan button 412 that may cause anassociated scanner to repeat the previous image capture. The userinterface 400 also includes a save button 414 that can be pressed by auser to save any changes made to the payment instrument image or theassociated metadata to the associated cash letter file. The userinterface 400 also includes an apply filter button 416 that will apply apredetermined filtering operation to the bi-tonal payment instrumentimage 402. In some implementations, the predetermined filteringoperation may include sharpening, enhancing, despeckling, adjustingcontrast, or other operations.

FIG. 5A is a diagram illustrating the example user interface 500 after aphysical check with a low contrast region 506 has been scanned. Asshown, the user interface 500 presents a bi-tonal payment instrumentimage 502, and the monochromatic payment instrument image 504. Themonochromatic payment instrument image 504 includes a light regionaround the amount, while the remainder of the image is predominantlydark. Accordingly, the corresponding bi-tonal payment instrument image502 includes a low contrast region 506 corresponding to this lightregion of the monochromatic payment instrument image 504. In creatingthe bi-tonal payment instrument image 502, the system chooses a contrastvalue based on the entire monochromatic payment instrument image 504.Because the remainder of the monochromatic payment instrument image 504is predominantly dark, the contrast value chosen by the system is high,causing the text within the low contrast region 506 to not be legible.Adjusting the contrast value for the entire bi-tonal image may notalleviate the problem, because by lowering the contrast value, more ofthe background pattern of the monochromatic payment instrument image 504will be included as black in the bi-tonal payment instrument image 502,which may obscure other details of the check.

FIG. 5B is a diagram illustrating the example user interface 500receiving an indication of an area to which to apply a contrastadjustment. As shown, a box 508 has been placed around the low contrastregion 506 to indicate that contrast should be adjusted. In someimplementations, the user may indicate an area to adjust by clicking anddragging a mouse to make a box or rectangle around the area. In somecases, the indication may be a different shape, such as, for example, acircle, an oval, a square, a triangle, or other shapes. The userinterface 500 may also allow the user to draw a freeform shape. In somecases, the user interface 500 may allow the user to indicate multipleareas of the bi-tonal payment instrument image 502 to adjustsimultaneously.

The user interface 500 includes a contrast adjustment slider 510 bywhich a user may indicate adjustments to the contrast of the area of thebi-tonal payment instrument image 502 selected by the box 508. Thecontrast adjustment slider 510 is shown in a first position 512. In someimplementations, the contrast adjustment slider 510 may be a differenttype of user interface component decides a slider, such as, for example,a text box, a drop-down list, a set of radio buttons, or other userinterface components.

FIG. 5C is a diagram illustrating the example user interface 500 afterperforming the contrast adjustment. As shown, the contrast adjustmentslider 510 has been moved to a second position 514. In response, thecontrast value of the area selected by the box 508 has been decreased,such that more pixels within the box 508 are interpreted as black.Accordingly, the amount within the low contrast region 506 (“$35.00”) isnow legible. In some cases, the low contrast region 506 may be analyzedto verify that it is in fact legible, such as by performing OCRprocessing or by using other techniques. Such a determination oflegibility may be based on standards of legibility defined by theFederal Reserve, the banking industry, a particular financialinstitution (e.g., the financial institution associated with the check),or other entities.

Although the preceding figures describe example implementationsinvolving performing contrast adjustments on areas of bi-tonal imagescreated from monochromatic images, the present disclosure is not limitedto this type of adjustment, and contemplates performing variousadjustments on various types of images. In some implementations, theoriginal payment instrument image may be a color image, and the clearingpayment instrument image may be a grayscale image. In such a case, theuser interface may allow the user to adjust weighting values associatedwith the red, green and blue values of each pixel when creating thegrayscale image. For example, if a certain pixel had a red intensity of10, a blue intensity of 11, and a green intensity of 0, and all threecolors were weighted evenly, the corresponding pixel in the grayscaleimage would have an intensity value of 7, calculated by averaging thethree color intensities. If the same pixel had an associated red weightof 0%, the intensity of the grayscale pixel would be based only on theblue and green intensities, yielding grayscale intensity ofapproximately 3.67 (11/3). In this way, certain colors may be filteredfrom the corresponding grayscale image by reducing their weights. Such afeature may be useful for original payment instrument images includingbackground patterns of a certain color. The user interface may allowaccess to such a feature by presenting the user with three sliderssimilar to the contrast adjustment slider 510, with each slidercontrolling a weighting value of a single color. Indicated areas of theclearing payment instrument image may be updated using these sliders inthe same manner described above relative to the contrast adjustmentslider 510.

In some implementations, the original payment instrument image may be acolor image, and the clearing payment instrument image may be a blackand white image. In such a case, the user interface may allow the userto adjust the weighting values associated with the red, green and bluevalues of each pixel as described above, and may also allow the user toadjust the contrast value used when creating the black and white image.The color intensities of a pixel may be averaged as described above toyield a gray intensity, and then the contrast value may be applied todetermine if the corresponding pixel in the clearing image should bewhite or black, similar to the process described above. In such animplementation, the user interface may include four sliders, one foreach color and one for the contrast value.

As described above, these techniques may be used to include informationin a clearing payment instrument image that would be lost using a globalcontrast adjustment. For example, in a case where the MICR line of acheck has been written over in black marker, there may be a slightdifference in the color of the MICR line and the black marker, such thata contrast adjustment may make the MICR line visible in the black andwhite clearing payment instrument image. In another example, a selectivecontrast adjustment may allow a highlighted piece of information on theimage, such as the address, to be included in the black and whiteclearing payment instrument image, whereas before it may have appearedas black.

FIG. 6 is flow chart showing an example method for allowing independentadjustment of different areas of a payment instrument image. For clarityof presentation, the description that follows generally describes method600 in the context of FIGS. 1-5. However, method 600 may be performed,for example, by any other suitable system, environment, software, andhardware, or a combination of systems, environments, software, andhardware, as appropriate.

At 605, an image property of an area of the clearing payment instrumentimage associated with a tangible payment instrument is updated. Thetangible payment instrument includes a payee, a payor, an amount, andauthorization. In some cases, the tangible payment instrument is to besubmitted for electronic transaction clearing. The tangible paymentinstrument may include at least one of a payment instrument, a moneyorder, a cashier's check, or a deposit slip. The clearing paymentinstrument image is associated with a first value of the image property,and the image property of the area is updated to a second valuedifferent than the first value of the image property. The area of theclearing payment instrument image includes less than the entire clearingpayment image.

At 610, the updated clearing payment instrument image is stored inresponse to updating the image property. In some implementations,storing the updated clearing payment instrument image includes insertingthe updated clearing payment instrument image into a cash letter file.

In some cases, the clearing payment instrument image is created based onan original payment instrument image associated with the tangiblepayment instrument prior to updating the image property. The clearingpayment instrument image may also be received from an external locationprior to updating the image property.

In some implementations, the original payment instrument image isidentified prior to creating the clearing payment instrument image.Identifying the original payment instrument image may include scanningthe tangible payment instrument with an image scanner, identifying theoriginal payment instrument image within a cash letter file, receivingthe original payment instrument image over a network in response to arequest, or other actions.

In some cases, identifying the original payment instrument imageincludes identifying a monochromatic payment instrument image, andcreating the clearing payment instrument image includes creating abi-tonal payment instrument image. In some implementations, themonochromatic payment instrument image is a grayscale payment instrumentimage, the bi-tonal payment instrument image is a black-and-whitepayment instrument image, and the image property includes contrast.

In some implementations, identifying the original payment instrumentimage includes identifying a color payment instrument image, and theimage property includes a red weight value, a green weight value, and ablue weight value. In such cases, creating the clearing paymentinstrument image from the original payment instrument image may includecreating a grayscale payment instrument image from the color paymentinstrument image based at least in part on the red weight value, thegreen weight value, and the blue weight value, and updating the imageproperty of the area of the clearing payment instrument image mayinclude updating at least one of the red weight value, the green weightvalue, or the blue weight value for the area.

The image property may also include a contrast threshold value, andcreating the clearing payment instrument image from the original paymentinstrument image may include creating a black-and-white paymentinstrument image from the color payment instrument image based at leastin part on the red weight value, the green weight value, the blue weightvalue, and the contrast threshold value, and updating the image propertyof the area of the clearing payment instrument image may includeupdating at least one of the red weight value, the green weight value,the blue weight value, or the contrast threshold value for the area. Insome cases, the contrast threshold value for each pixel may be stored inan alpha channel of the original payment instrument image, the clearingpayment instrument image, or both images.

In some cases, the clearing payment instrument image may be a colorimage, and updating the image property may include adjusting colorlevels so that information from the tangible payment instrument (e.g.,payor, payee, amount, etc.) is legible in the clearing paymentinstrument image.

In some implementations, the clearing payment instrument image ispresented in a user interface in response to creating the clearingpayment instrument image, an indication of the area of the clearingpayment instrument image to adjust is received from the user interface,and an indication of the second value of the image property is receivedfrom the user interface. In some implementations, the user interfacedoes not allow updating of image properties of the indicated area of theclearing payment instrument image other than the image property.

In some cases, updating the value of the area of the clearing paymentinstrument image to the second value includes determining that theupdated area of the clearing payment instrument image is legible basedat least in part on requirements of an electronic payment instrumentclearing process.

In some implementations, identifying information is extracted from afirst clearing payment instrument image, the second value of the imageproperty and the area are associated with the identifying informationfrom the first clearing payment instrument image. A determination isthen made that a second original payment instrument image associatedwith a second tangible payment instrument different than the firsttangible payment instrument includes the identifying information. Thesecond clearing payment instrument image is updated based on the secondoriginal payment instrument image based on the second value of the imageproperty and the area associated with the identifying information. Insome cases, the identifying information includes an account number and arouting number.

FIG. 7 is flow chart showing an example method for allowing independentadjustment for different areas of a payment instrument image. Forclarity of presentation, the description that follows generallydescribes method 700 in the context of FIGS. 1-5. However, method 700may be performed, for example, by any other suitable system,environment, software, and hardware, or a combination of systems,environments, software, and hardware, as appropriate.

At 705, and original payment instrument image is received from a remotestorage location. In some implementations, the original paymentinstrument image may be received at a user station. In some cases, theremote storage location is an archive storing one or more originalpayment instrument images. In some cases, the remote storage location isan image scanner, and the user station receiving the original paymentinstrument image includes receiving a scanned image of the tangiblepayment instrument. In some implementations, the tangible paymentinstrument includes at least one of a payment instrument, a money order,a cashier's check, or a deposit slip.

At 710, the clearing payment instrument image associated with theoriginal payment instrument image is presented in a user interface inresponse to receiving the original payment instrument image. Theclearing payment instrument image is associated with a first value ofimage property. In some cases, the image property is contrast. At 715,an indication of an area of the clearing payment instrument image toupdate is received from the user interface. At 720, an indication of asecond value of the image property is received from the user interface,the second value indicating a value to which to update the indicatedarea. The second value may be different than the first value of theimage property.

At 725, the image property of the indicated area is updated to thesecond value in response to receiving the indication of the area and thesecond value of the image property. In some cases, the user interfacedoes not allow updating of image properties of the indicated area of theclearing payment instrument image other than the image property.

In some cases, the updated clearing payment instrument image may bestored in response to updating the image property of the indicated area.Storing the updated clearing payment instrument image may includeinserting the updated clearing payment instrument image into a cashletter file.

In some implementations, updating the image property may be limited toavoid allowing the payment instrument image to be improperlymanipulated. For example, in implementations where the image property iscontrast, it may be possible to set the contrast value for an area toturn the entire area black. If adjustment of very small area of thepayment instrument image is allowed, it may be possible for additionalinformation to be introduced into the payment instrument image. For thisreason, limitations on the adjustment parameters may be enforced. Forexample, contrast adjustment may be limited to not allow the contrastthreshold for a region to be set low enough to turn the entire regionblack. Contrast adjustment may also be limited so that only regions overa certain size may be adjusted, thereby preventing the adjustment ofsmall groups of pixels to modify the payment instrument image.Additionally, image adjustment behavior that may indicate fraud may betagged for further review. For example, if an analyst spends greaterthan a certain amount of time adjusting a particular payment instrumentimage, the image may be flagged for further review. In another example,if an analyst performs more than a certain number of individualadjustments to the same payment instrument image, the image may besimilarly flagged.

FIG. 8 is flow chart showing an example method for allowing independentadjustment for different areas of a payment instrument image. Forclarity of presentation, the description that follows generallydescribes method 800 in the context of FIGS. 1-5. However, method 800may be performed, for example, by any other suitable system,environment, software, and hardware, or a combination of systems,environments, software, and hardware, as appropriate.

At 805, an image property of an area of the clearing payment imageassociated with a tangible payment instrument is updated, the tangiblepayment instrument including a payee, a payor, an amount, and anauthorization. The image property of the area is updated to a secondvalue different than a first value of the image property associated witha rejected clearing payment image that is unsuitable for electronictransaction clearing, and the area of the clearing payment instrumentimage includes less than the entire clearing payment image. In somecases, the rejected clearing payment image is associated with arejection reason indicating why the rejected clearing payment image isunsuitable for electronic transaction clearing. The rejection reason mayinclude one or more of a missing corner, image noise, image skew,darkness, or other reasons. The rejection reason may also includeillegibility of at least one of the payee, the payor, the amount, theauthorization, or other information. At 810, the updated clearingpayment instrument image is stored in response to updating the imageproperty.

FIG. 9 is flow chart showing an example method for allowing independentcontrast adjustment for different areas of a payment instrument image.For clarity of presentation, the description that follows generallydescribes method 900 in the context of FIGS. 1-5. However, method 900may be performed, for example, by any other suitable system,environment, software, and hardware, or a combination of systems,environments, software, and hardware, as appropriate.

At 905, the original payment instrument image associated with a tangiblepayment instrument is received, the tangible payment instrument to besubmitted for electronic transaction clearing and including a payee, apayor, an amount, and an authorization. In some cases, receiving theoriginal payment instrument image associated with the tangible paymentinstrument includes receiving the original payment instrument image froman image scanner.

At 910, a clearing payment instrument image is created based on theoriginal payment instrument image, the clearing payment instrument imageassociated with a first contrast value. In some cases, the originalpayment instrument image is a monochromatic image, and creating theclearing image includes is a bi-tonal image. The monochromatic image maybe a grayscale image, and the bi-tonal image may be a black-and-whiteimage. In some cases, the original payment instrument image is a colorimage.

At 915, the clearing payment instrument image is presented in the userinterface in response to creating the clearing payment instrument image.

At 920, an indication of an area of the clearing payment instrumentimage is received from the user interface, the indicated area includingless than the entire clearing payment instrument image.

At 925, an indication of a second contrast value to which to update theindicated area is received from the user interface, the second contrastvalue being different than the first contrast value. In some cases, theuser interface does not allow updating of image properties of theindicated area of the clearing payment instrument image other than thecontrast.

At 930, a contrast value of the indicated area of the clearing paymentinstrument image is updated to the second contrast value in response toreceiving the indication of the area and receiving the indication of thesecond contrast value from the user interface. In some cases, theupdated clearing payment instrument image is inserted into a cash letterfile.

In implementations where the original payment instrument image is acolor image, an indication of a red weight value, a green weight value,and a blue weight value may be received from the user interface; and theindicated area of the clearing payment instrument image may be updatedbased on the red weight value, the green weight value, and the blueweight value in response to receiving the indication of the weightvalue, the green weight value, and the blue weight value from the userinterface.

The preceding figures and accompanying description illustrate exampleprocesses and computer implementable techniques. Environment 100 (or itssoftware or other components) contemplates using, implementing, orexecuting any suitable technique for performing these and other tasks.These processes are for illustration purposes only and that thedescribed or similar techniques may be performed at any appropriatetime, including concurrently, individually, or in combination. Inaddition, many of the steps in these processes may take placesimultaneously, concurrently, and/or in different order than as shown.Moreover, environment 100 may use processes with additional steps, fewersteps, and/or different steps, so long as the methods remainappropriate.

In other words, although this disclosure has been described in terms ofcertain implementations and generally associated methods, alterationsand permutations of these implementations and methods will be apparentto those skilled in the art. Accordingly, the above description ofexample implementations does not define or constrain this disclosure.Other changes, substitutions, and alterations are also possible withoutdeparting from the spirit and scope of this disclosure.

1-34. (canceled)
 35. A computer-implemented method executed by one ormore processors, the method comprising: identifying a payment instrumentimage including a payee, a payor, an amount, and an authorization,wherein the payment instrument image associated with a tangible paymentinstrument to be submitted for electronic transaction clearing, andwherein the payment instrument image is associated with a first value ofan image property; identifying an area of the payment instrument imagefor which the image property is to be updated and a second value for theimage property different than the first value, wherein the area of thepayment instrument image includes less than the entire paymentinstrument image; updating the image property of the identified area ofthe payment instrument image to the second value for the image property,wherein the image property of other areas of the payment instrumentimage remains at the first value of the image property, and storing theupdated payment instrument image in response to updating the imageproperty.
 36. The method of claim 35, wherein the image property iscontrast.
 37. The method of claim 35, wherein identifying an area of thepayment instrument image for which the image property is to be updatedand a second value for the image property is performed automatically.38. The method of claim 37, wherein the payment instrument image isassociated with a rejected payment image that is unsuitable forelectronic transaction clearing, the rejected payment image associatedwith a rejection reason indicating why the rejected clearing paymentimage is unsuitable for electronic transaction clearing, and identifyingthe area of the payment instrument image for which the image property isto be updated and the second value for the image property is performedbased on the rejection reason.
 39. The method of claim 38, wherein therejection reason includes at least one of a missing corner, image noise,image skew, or darkness.
 40. The method of claim 38, wherein therejection reason includes illegibility of at least one of the payee, thepayor, the amount, or the authorization.
 41. The method of claim 35,wherein identifying the area of the payment instrument image for whichthe image property is to be updated and the second value for the imageproperty different than the first value includes: presenting the paymentinstrument image in a user interface; receiving an indication of thearea of the payment instrument image to adjust from the user interface;and receiving an indication of the second value of the image propertyfrom the user interface.
 42. The method of claim 41, wherein the userinterface does not allow updating of image properties of the indicatedarea of the payment instrument image other than the image property. 43.The method of claim 35, wherein the tangible payment instrument includesat least one of a payment instrument, a money order, a cashier's check,or a deposit slip.
 44. The method of claim 35, wherein updating thevalue of the area of the payment instrument image to the second valueincludes determining that the updated area of the payment instrumentimage is legible based at least in part on requirements of an electronicpayment instrument clearing process.
 45. The method of claim 35, whereinthe tangible payment instrument is a first tangible payment instrument,and the payment instrument image is a first payment instrument image,the method further comprising: identifying information from the firstpayment instrument image; associating the second value of the imageproperty and the area of the first payment instrument image with theidentifying information from the first payment instrument image;determining that a second payment instrument image associated with asecond tangible payment instrument different than the first tangiblepayment instrument includes the identifying information; and updatingthe second payment instrument image based on the second value of theimage property and the area of the first payment instrument imageassociated with the identifying information.
 46. The method of claim 45,wherein the identifying information includes an account number and arouting number.
 47. The method of claim 35, wherein the paymentinstrument image includes an alpha channel storing a value of the imageproperty for each pixel in the updated payment instrument image.
 48. Anon-transitory, computer-readable medium storing instructions operablewhen executed to cause at least one processor to perform operationscomprising: identifying a payment instrument image including a payee, apayor, an amount, and an authorization, wherein the payment instrumentimage associated with a tangible payment instrument to be submitted forelectronic transaction clearing, and wherein the payment instrumentimage is associated with a first value of an image property; identifyingan area of the payment instrument image for which the image property isto be updated and a second value for the image property different thanthe first value, wherein the area of the payment instrument imageincludes less than the entire payment instrument image; updating theimage property of the identified area of the payment instrument image tothe second value for the image property, wherein the image property ofother areas of the payment instrument image remains at the first valueof the image property, and storing the updated payment instrument imagein response to updating the image property.
 49. The non-transitory,computer-readable medium of claim 48, wherein the image property iscontrast.
 50. The non-transitory, computer-readable medium of claim 48,wherein identifying an area of the payment instrument image for whichthe image property is to be updated and a second value for the imageproperty is performed automatically.
 51. The non-transitory,computer-readable medium of claim 50, wherein the payment instrumentimage is associated with a rejected payment image that is unsuitable forelectronic transaction clearing, the rejected payment image associatedwith a rejection reason indicating why the rejected clearing paymentimage is unsuitable for electronic transaction clearing, and identifyingthe area of the payment instrument image for which the image property isto be updated and the second value for the image property is performedbased on the rejection reason.
 52. The non-transitory, computer-readablemedium of claim 51, wherein the rejection reason includes at least oneof a missing corner, image noise, image skew, or darkness.
 53. Thenon-transitory, computer-readable medium of claim 51, wherein therejection reason includes illegibility of at least one of the payee, thepayor, the amount, or the authorization.
 54. A system comprising: memoryfor storing data; and one or more processors operable to performoperations comprising: identifying a payment instrument image includinga payee, a payor, an amount, and an authorization, wherein the paymentinstrument image associated with a tangible payment instrument to besubmitted for electronic transaction clearing, and wherein the paymentinstrument image is associated with a first value of an image property;identifying an area of the payment instrument image for which the imageproperty is to be updated and a second value for the image propertydifferent than the first value, wherein the area of the paymentinstrument image includes less than the entire payment instrument image;updating the image property of the identified area of the paymentinstrument image to the second value for the image property, wherein theimage property of other areas of the payment instrument image remains atthe first value of the image property, and storing the updated paymentinstrument image in response to updating the image property.